[セッションレポート] Amazon RDS for Aurora: Re-imagine the Relational Database #reinvent

AWS re:Invent 2014

#Amazon Aurora

#Amazon RDS

#AWS

望月政夫

2014.11.13

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

本日 re:InventのKeynoteで発表されたMySQL互換の新しいDBエンジン「Amazon Aurora」の紹介セッションに参加してきました。以下レポートです。

内容

導入

既存のRDBというのはモノリシックなデザインになっている。
- SQL
- トランザクション
- キャッシュ
- ロギング
この構成が1970年代から続いているが、クラウド時代の今、コスト、柔軟性、可用性の意味でデータベースを「re-imagine」して「re-invent」しよう、というところ。
エンタープライズクラスのデータベースの機能をオープンソースデータベースと同じ価格で、というのがAmazon Auroraのコンセプト。

Aurora

マルチテナント
ロギングとストレージ領域はSQL、トランザクション、キャッシュなどのノードからは分離された
MySQL 5.6との完全な互換性。

1AZに2つのデータ領域がコピーされる。
SSDベースで64TBのストレージまでをサポートする。シームレスなストレージ領域の拡張が可能。

既存DBとの違い

クラッシュリカバリ手法
- 既存DB : チェックポイントからのredoログ適用
- Aurora: ブロックごとにもつredoログをread処理時に適用

再起動時
- 既存DB : リザルトキャッシュはすべて消える
- Aurora : 一旦永続領域にキャッシュを退避するので再起動後もキャッシュは残る
リードレプリカ
- MySQL : スレーブに対してbinlogが送信され、slaveノードでも書き込み処理を実施する必要がある。
- Aurora : 各々のDBノードが共通のストレージを参照しているため、スレーブでの書き込み処理は発生しない。masterへの書き込みが多い時でも安定してREADが実行できる。書き込み発生後はSlaveにたいして該当レコードのキャッシュInvalidationが送られる。
障害シミュレートが可能
- クラウド環境ではN/W障害などを故意に起こすことが難しいので、障害をシミュレートするためのSQLが用意されている。
  - DB Node障害
  - Disk
  - N/W
- 例 : ALTER SYSTEM CRASH NODE;

パフォーマンス

performance
- Aurora R3.8xlarge(32 core 244GB RAM)で検証
- 秒間105,000回のWrite.
- 秒間546,000回のRead.
- 138,000/秒の書き込み実施時のレプリケーション遅延は7.27ms
- MySQL5.6では、2,000/秒の書き込み時に遅延が2秒ほど発生する
テーブル数が増加してもパフォーマンスにほとんど影響しない
同時接続数が増加してもパフォーマンスが劣化しづらい
大量の書き込みがあってもレプリケーション遅延は大きくならない
現在はLimited Preview版。2015年上旬には正式に公開される予定。

Q&A

様々なQ&Aがあり、全部は追いきれませんでしたが一部。

Q: データの暗号化は？
- A: 今後サポート予定。
Q: MySQLからの移行はどうしたらいい？
- A: MySQL5.6と同じなので既に5.6を使っている場合はシンプルに移行が可能。5.1や5.5の場合は5.6に上げるのと同じステップが必要。
Q: マルチリージョンでの利用は？クロスリージョンスナップショットは？
- A: 今後のロードマップには存在している。
Q: Dedicated形式で利用できないか？
- A: 現在は考えていない。今後対応があるかも

まとめ

本日発表されたAuroraは注目度も相当高く、広いセッション会場は満員でした。何度も「I/FはMySQL 5.6と同じ」というのを強調されていたのが印象的でした。Beta版には申し込んでみたので、Acceptされたら一度使ってみたいと思います。個人的にはクラウドの利点という意味でマルチリージョン対応が進むと嬉しいなー、と考えています。あとは意図的にCrashさせることができるコマンドをネイティブで持っているのは素晴らしいと思います。